Static code analysis is analysis of computer software that is performed using an automated software tool without actual execution of the programs built from the software. Some example uses of static analysis are to identify generic errors (such as memory corruption and data races) and system-specific or interface-specific violations (such as violations of function-ordering constraints). Static analysis also may be employed to identify security vulnerabilities, for example.
Static analysis can be used to detect kinds of errors that are often missed when using dynamic analysis techniques that involve actual execution of the program code. For example, static analysis may detect an illegal operation that is contained in a rarely traversed or otherwise hard-to-test conditional branch code path that is rarely visited during operation of the software, and that therefore, easily could go undetected during dynamic analysis. Static analysis ordinarily involves use of a variety of different checkers to evaluate code paths to identify different kinds of vulnerabilities and/or errors. For example, checkers can be used to detect syntax errors, functions without return values, variables that have been declared but not used, inadvisable automatic type conversions, tainted data, integer overflows, global-variable inconsistencies, problems associated with using modules (e.g., missing or invalid modules or input/export mismatches), to name just a few.
Static analysis techniques have been developed that utilize information generated during a build process to identify the code that is to be subjected to analysis. Modern software typically is developed using a modular approach. Teams of programmers may work on different modules or portions of the software. Consequently, source code, compilers, and ancillary software components often are distributed across many different directories and systems. As a result of this complexity, software developers typically use build management utilities such as the “make” program to assist in the process of building executable code. During a typical software development process, source code either represents an executable script in a high-level programming language, or is compiled to produce byte code that needs to be further interpreted by an interpreter program and/or executable binary code that runs directly on the CPU. Different portions of the software may be written using different programming languages that require the use of different compilers, for example. Moreover, different compilers may be used to compile different portions of the source code, even when all of the code is written in the same language. For example, different compilers may produce executable code that runs on computer systems with different microprocessors. A ‘build’ process, which involves identifying the source code files associated with a program and establishing appropriate directory locations, compiler names, and other compilation settings involves many steps, and software developers typically automate such a build process using what typically is referred to as a build program. Static analysis processes may leverage information about source code that is made available during the build process by intercepting information that identifies the code to be statically analyzed. Commonly owned U.S. Pat. No. 7,340,726 invented by Chelf et al. describes examples of some known static analysis techniques that leverage information about code made available during a build process.
A computer code based system may comprise multiple code components that have dependency relationships among them. The code components (hereinafter ‘components’) of a computer code based system are stored in a non-transitory computer readable storage device and are used together to configure a general purpose computer system to perform specific functions. During development of such a computer code based system, individual components may be changed, and changes in these individual components may have an impact upon other components that are dependent upon the changed components even though the other components themselves are unchanged.
FIG. 1 is an illustrative diagram showing relationships among code components of an example computer code based system. In this example, the code of certain components has been changed, but the code of other components is unchanged. The changes to the code components have an impact upon other components even though the impacted code components have not themselves been changed. The impacted components in the example are dependent upon the changed components. Change impact can “ripple” through the computer code based system from the changed components to unchanged components that depend upon the changed components. Not all components that are dependent upon the changed components are impacted by the changes. Moreover, legacy components in the example that are not dependent upon the changed components are not impacted by the changes.
It is possible to use static analysis to analyze the impact that changes to the code of some components have upon unchanged components that have a dependent relationship with changed components.